Support serializing anonymous and local class with custom adapter #2498
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose
Resolves #1510
(but only for the cases where a custom adapter exists for the class; not if the reflection-based adapter would be used)
Description
When serializing an anonymous or local class for which a custom adapter exists (i.e. not the reflection-based adapter), it will now use that adapter instead of serializing
null
.Deserialization is still not supported, even if a custom adapter exists, because some custom adapters like the built-in
Collection
adapter might fall back to using JDK Unsafe to create an instance, and that might lead to runtime exceptions then due to uninitialized fields. Also, for deserialization this issue most likely can only occur for local classes, and can be worked around by making the class non-local.Future topics:
(And are there possibly cases where a field is compiler-generated but not marked as synthetic?)
(The main issue here is making sure JDK Unsafe is not used to create an instance of such a class, to avoid ending up with uninitialized fields.)
I am not planning to submit any pull requests for these future topics yet. It might be better if we first see which of these features the users actually need, and if these use cases are common.
Checklist
null
@since $next-version$
(
$next-version$
is a special placeholder which is automatically replaced during release)TestCase
)mvn clean verify javadoc:jar
passes without errors